Enterprise Resource Planning (“ERP”) software is a type of software used by many companies to plan and manage various business functions, such as budgeting, accounting, human resources, inventory, customer relationships, and so on. ERP software typically provides access to a database from which users and applications may retrieve information related to the various business functions. Users and application resources typically interact with the database via a plurality of database objects. For example, a table object may provide access to a data table while a form object may provide the code necessary for displaying a form that can be used to access data with a table. As another example, a codeunit may provide logic for manipulating the data and objects associated with the database. In addition to the above-mentioned objects, typical objects may also include reports, records, menu suites, dataports, and XMLports. These objects may be considered to be metadata because they contain information that describes the layout of forms, schema of a database table, and so on.
ERP software is typically implemented as part of an ERP system that is based on a client/server model. A server of the ERP system functions as a front end to the database of the objects and includes server components that provide server-side business logic. The clients of the ERP system include client components that interact with the server to perform functions requested by a user. When a user requests a function to be performed, the client may send a request to the server for objects that are needed to satisfy the request. For example, the client may need a form object and a table object relating to customer information to satisfy a request to update customer information. Upon receiving the request, the server then accesses the database to retrieve the objects needed to satisfy the request. Upon receiving the objects from the database, the server sends those objects to the client to allow the function requested by the user to be performed.
The database for an ERP system may contain thousands of tables with many of the tables having thousands and millions of rows. For example, a large telephone company may have millions of customers. The ERP system for such a telephone company may have a customer table with a row for each customer. The ERP system may also have a call table that includes a row for each telephone call placed by each customer. The telephone company may have multiple customer service centers with service representatives who have access to review and modify the database tables to reflect interactions with customers. Because the customers and customer service centers may be located throughout the world, the telephone company would like to have access to the ERP system 24 hours a day, seven days a week.
From time to time, the application database of an application (e.g., ERP system) may need to be converted from its current version to an upgraded version. For example, the developer of the application may develop enhanced functionality that only can be provided by modifying the schema of the database. As another example, a government entity may require certain data to be maintained by a company, which in turn requires a change to the schema of the application database. As yet another example, the data of a field may need to be converted from one format to another without changing the schema such as converting miles to kilometers. The terms conversion or upgrading of a database are used herein to refer to the changing of the schema and/or the data of application data rather than upgrading the underlying database system.
Current techniques for converting an application database typically require that the application be effectively shutdown so that users cannot use the application to change the data in the database during the conversion. Some databases may prevent users from changing the data by opening the database in single-user access mode, rather than multi-user access mode. In single-user access mode, only one user—typically a system administrator—is allowed to update the database at a time. In contrast, when the database is opened in multi-user access mode, many different users can update the database simultaneously. If a conversion requires the database to be opened in single-user access mode, then no other users can update the database at the same time. For example, all the customer service centers for a telephone company may need to be shut down during a database conversion because the database can only be opened in single-user access mode during the conversion. Since conversions on large databases can take many hours or even days, organizations are typically reluctant to convert their database to take advantage of a new functionality or to satisfy government regulations.
Although the conversion of some databases may occur while the database is opened in multi-user access mode, such a conversion is typically not desirable for several reasons. First, if a conversion process is started but fails for some reason, the database may be left in an inconsistent state. In such a case, in order to bring the database back into a consistent state, the updates to the database would need to be effectively undone by, for example, rolling back the updates or restoring an archived version of the database. Second, since multiple users may be updating the database during the conversion, the conversion process needs to recognize changes made to the database while the conversion is occurring so that the converted database includes all of the changes. Some conversion techniques may request that triggers be activated whenever an update to the database occurs so that the conversion process can ensure that the converted database reflects those updates. Such a triggering mechanism places a high overhead on ERP system, resulting in an overall slowdown of the ERP system. Third, during the conversion process, a conversion system may need to lock various tables at various times. The locking of tables may effectively lock out other users from accessing those tables, which also would result in an overall slowdown of the ERP system.